谷歌遇到了金丝雀问题：超时问题搞砸了云；集中式很危险

这种事又一次发生了。所以现在，谷歌在重新构建集中式路由设备（注：集中式很危险）。

谷歌公司近日解释了为何在今年1月份其云引擎中新的云虚拟机有几小时无法接到全世界：一只金丝雀没有从栖枝掉下来，换句话说一个金丝雀版本没有顺利通过测试，所以公司不知道有这么个问题。

事件其实并不严重：1月30日，刚创建的谷歌计算引擎（Google Compute Engine）实例、Cloud VPN和网络负载均衡系统无法使用，这个故障持续了两个小时多点。虽然受影响的服务器拥有公共IP地址，但是无法从外界来加以访问，它们也无法发送任何流量。负载均衡运行状况检查机制也失效了。

谷歌解释了那起事故，这让我们对其基础设施有了一点了解。以下是它向我们所有人解释的根源：

对GCE实例、负载均衡系统和VPN隧道而言，所有的入站网络流量都通过共享的第2层负载均衡系统进入。这些负载均衡系统针对这些资源进行了配置，对IP地址作了相应的更改，然后在金丝雀部署（canary deployment）中自动进行了测试，最后向全世界部署更改。

这个问题是由针对一种很少使用的负载均衡配置部署的一大批更新版引起的。将这些更新版部署到该配置上，暴露了一条低效的代码路径，因而最终导致了金丝雀版本超时。之后，公共寻址的所有变更都排在了未能通过测试阶段的这些变更之后的队列中。

一旦谷歌的工作人员查明了感到困惑的金丝雀版本是问题的根源，他们“重新启动了负责对网络负载均衡系统进行编程更改的作业”，然后成批处理有问题的变更。这在短时间内解决了问题。

现在，谷歌“延长了金丝雀版本的超时时间，那样选用低效代码路径的更新版仅仅让网络更改缓慢进行，而不是完全终止网络更改。”

这不是谷歌头一次遇到金丝雀问题了：2016年10月，它的其中一个金丝雀版本未能成功部署，结果谷歌云的一部分瘫痪。

谷歌一劳永逸的解决办法就是推出新的测试来测试更多的配置，并且将低效代码路径隔离起来。该公司认为，自己已经在采取措施解决这类问题，为此实施了更加分布式的路由。眼下正在加快这项工作，“因为这可以阻止这一层面的问题影响全世界。”

当然，谷歌表示，它现在正在制定新的度量指标，那样系统会更迅速地提醒出现的问题。也许谷歌需要一架开发运维（DevOps）飞碟（UFO）在第一时间通告突发问题？

云头条编译｜未经授权谢绝转载

相关阅读：